ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group92c.txt/000039_icon-group-sender _Fri Oct 23 18:35:37 1992.msg

Internet Message Format | 1993-01-04 | 4KB

Received: by cheltenham.cs.arizona.edu; Wed, 28 Oct 1992 09:35:27 MST
Date: 23 Oct 92 18:35:37 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: Re: confusing errors
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Status: R
Errors-To: [e-mail]

[e-mail] writes:

>|>|If anybody find the Icon tokenizer interesting (automatic semicolon inser-
>|>|tion is really a great idea - why don't all languages do it?), then here's
>|>|a fun program.
>|>
>|>Makes about as much sense as automatic plus insertion or automatic
>|>atanh() insertion, if you ask me.
>|
>|I didn't ask, Stephen, but since you interject I respond with a basic
>|remark about tokens and their semantics:  Some terminals map to nodes
>|in the abstract syntax tree; some only demarcate expressions.  When and
>|if they are superfluous, they should be eliminated, as long as doing so
>|does not render the language more opaque.
>
>But but but. The semicolon operator DOES have semantics: it explicitly
>evaluates and discards its left argument and returns its right! It's the
>most drastic operator in the book! Now *parentheses*, I grant, don't do
>anything at abstract syntax. Wanna make THOSE optional?

But but but!  Parentheses serve to group expressions where the precedences
or associativities are not clear.  There are only a couple of declarations
in Icon; just about everything else can be an expression.  So there's no
practical need for the semicolon:  If anyone is confused, use parentheses.
To bound an expression a line-break is quite enough.  Just as clear as a
semicolon.  If one wants to compact several bounded expressions onto a
single line, then the semicolon *may* be used.  The following is perfectly
legal Icon code:

    procedure main()
        write("hello world"); exit(0)
    end

The following is also legal:

    procedure main()
        write("hello world")
        exit(0)
    end

After you read Icon for a couple of weeks, superfluous semicolons start to
seem like an annoying tick.  There's no reason for them.  The analyzer can
figure things out perfectly well without them.

>|Opacity is a subjective judgment, of course, so let's check to see if
>|you know Icon in the first place.  Can you illustrate where automatic
>|semicolon insertion might render Icon source code less readable, or
>|introduce unexpected behavior?  I'm waiting....
>
>Nono, not my point. It reduces regularity in the language, limits the
>ease with it can be read and written automatically, and increases the
>potential for errors to be introduced during the editing process.

If you like regularity, just use LISP.  It is very easy to read and write
automatically, and its syntax is trivial.  In fact, Icon is very easy to
tokenize with automatic semicolon insertion, and I've never had any prob-
lems reading or writing it.  Not as regular as LISP, but then LISP code
is really not all that readable unless formatted with great skill (and a
smart editor).  Syntactic regularity != usability.

Maybe you are just baiting me, but the semicolon is not an operator with
abstract semantics.  It has semantics only in the sense that it directs the
syntactic analyzer to map the concrete syntax to the abstract syntax in a
certain way.  If this action can be determined easily enough without the
extra symbol, then why use it?  Make it optional for those few cases where
clarity would be served by its addition.

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]          rutgers!oddjob!ellis!goer